Enterprises today rely on database technology to run their businesses. Mission-critical and other data assets stored in the databases need to be safeguarded from inappropriate access and data changes. The need to protect data security and privacy has become of paramount concern to most organizations. Reasons for this concern include customer or supplier requirements, business practices, security policies and government regulations. Beyond what is commonly understood by “security,” that is, preventing unauthorized access, there is a driving need for data access accountability: knowing who is doing what to which data and by what means.
Capturing a record of data accesses is a key step in maintaining the data accountability, yet common existing approaches may miss certain kinds of activity, introduce a false sense of security or interfere with runtime database performance. These approaches include application modification, mid-tier portals and trigger-based collection at the data source.
Application modification entails changing source code of every application that might be used to access the data of interest. Each application is changed so that it captures data modification and viewing information and stores it for further processing. Because each application must be modified, application modification can substantially increase the implementation cost of compliance with data auditing requirements. This may be especially true where legacy systems must be brought into compliance. In addition, this approach requires each application to be modified and does not capture activity outside the modified application, thus reducing confidence in the completeness of the audit trail. The audit trail may be incomplete because operations not handled by the modified applications may be missed, or because the audit does not record access directly to the underlying database.
The mid-tier portal approach funnels access to data from multiple applications or users through a shared portal that is responsible for the backend access. This portal can be modified to capture and store data access information. As with the application modification approach, the mid-tier portal approach may pose potential risks because operations and accesses outside of the portal enabled applications may be missed by the audit trail. Implementation costs may be high as well because other approaches to creating audit trails would be needed where data were not created, modified, or deleted through the portal-enabled applications. This limitation of the portal approach may make it an especially inappropriate solution for many legacy systems that contain data subject to the data auditing requirement.
The most common way of capturing data modification is using database triggers. A trigger is a special-purpose application logic that is executed when predetermined events occur. Triggers have a number of drawbacks: they are often hard to write correctly, they add substantial runtime performance overhead because they execute in line with transactions, they cannot capture data views, and they cannot generally capture changes to database schema and permissions. In addition, triggers may easily be disabled without detection. The performance cost often leads database administrators to minimize the number of triggers implemented, thus reducing completeness of the audit trail.
How a data access accountability solution captures the appropriate data for an audit trail is as important as determining what data should be captured. Once the appropriate level of detail for the audit trail is determined, an effective solution should provide confidence that all the relevant activities that create, modify or delete data will be captured and activities will not inadvertently be omitted from the audit trail.